在軟體開發中，很常有個慣性是，希望將某個元件都打造的最完整，在開始打造下一個元件，而且通常都是從很底層的地方開始。像是會先設計好非常彈性又完整的資料庫、資料表，然後寫好後端程式與設計好完備的 API，最後在開始寫前端頁面。

但其實這樣就會導致使用者需要很長的時間才會看到第一個成品，很有可能會發現不是使用者要的，或是其實市場只要產品有 20% 的功能就可以開始賺錢了，那些錯過的時間都是種浪費。

也有可能底層都打造完美時，才發現前端那部分不需要這麼多功能，最後這些功能也不過是養灰塵，這也是種浪費呀。

從抽象的軟體開發領域先抽離出來，來想想現實有什麼情況可以類比。想想看，今天假設我們正在玩即時戰略，比如說類似世紀帝國這樣的遊戲好了（玩過的讀者留言認個同好吧！），我會怎麼去進攻敵人？

小時候的我，總是等到家裡都生產一堆兵後，浩浩湯湯的出發，準備橫掃千軍，最後繞了一大圈才發現敵軍根本不在我指定的目的地，甚至只不過離我基地數個螢幕的距離罷了。更悲劇的可能是，我到了敵軍加時，才發現我生產的兵種，根本被對方完剋，馬上就被清得一乾二凈。

其實更好的做法應該是，我先派幾隻斥候組成的小隊，先到處探路，嘗試打穿迷霧探到我方基地到敵方基地的路程，再根據對方的防禦建設、兵種，去生產各項兵種，逐漸攻佔。沿路上也會在必要處設置我方的建設。

這其實就是敏捷開發常講的 MVP、End-to-End、Spike 或是 Daniel Tang 所謂的打穿的概念。這幾種詞在細節上不全然相同，但都在揭示我們應該先以最小成本去探清未知、不明確、模糊的地帶，再根據回饋逐漸擴大投入，取得更好的成效。